home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1992 June: ROMin Holiday / ADC Developer CD (1992-06) (''ROMin Holiday'')_iso / Developer Connection - 06-1992.iso / Development Platforms / Apple II / Essentials / Technical.Notes / ATLK / TN.ATLK.008 < prev    next >
Encoding:
Text File  |  1990-09-21  |  7.2 KB  |  133 lines  |  [TEXT/pdos]
  1. Apple II
  2. Technical Notes
  3. _____________________________________________________________________________
  4.                                                   Developer Technical Support
  5.  
  6. AppleTalk
  7. #8:    Using The @ Prefix
  8.  
  9. Written by:    Jim Luther & Dan Strnad                         September 1990
  10.  
  11. This Technical Note discusses use the @ prefix with multiple users.
  12. _____________________________________________________________________________
  13.  
  14. Apple II computers on AppleShare networks feature a unique folder for each 
  15. user on the server volume, called the user's folder.  Server volumes 
  16. containing these user's folders are called user volumes.  User's folders exist 
  17. on user volumes so that the system and applications have a standard place to 
  18. store user-specific data on the network.  All network volumes an Apple II can 
  19. boot from are user volumes.
  20.  
  21. Under GS/OS, the @ prefix allows applications to automatically work with the 
  22. user's folder.  If a user launches your application from a server volume with 
  23. a user volume mounted, GS/OS sets the @ prefix to the user's folder; otherwise 
  24. it sets it to the application folder.  The @ prefix can reduce design and 
  25. coding effort for multilaunch features by providing the application with the 
  26. system's best guess at where user-specific information should be stored.  To 
  27. safely use the user's folder feature, programmers need only remember to use 
  28. the @ prefix with the GS/OS class 1 Open call (requestAccess = 1, 2, or 3).  
  29. Using the @ prefix with the class 1 Open provides safe access to the file for 
  30. as long as it remains open, without requiring any network-specific code.
  31.  
  32. Using the @ prefix is appropriate for applications that want to avoid network-
  33. specific programming while being reasonably well-behaved in a network 
  34. environment.  For example, applications may store printer defaults in the @ 
  35. directory or use it as a default when prompting the user to choose a 
  36. directory.
  37.  
  38. There are situations writing data to a file in the @ directory could result in 
  39. other users overwriting the data; however, applications may reasonably require 
  40. that users not allow these situations to occur   In Table 1, the third through 
  41. fifth cases are all situations in which this problem could occur.  For best 
  42. results, when opening a file for writing with the @ prefix, use access 
  43. privileges that deny write access to other users.  The GS/OS class one Open 
  44. call always does this when requestAccess is non-zero.  Without this precaution 
  45. of denying write access to other users, the user's data is not protected from 
  46. being overwritten while it is in use.
  47.  
  48. Application   Is a
  49. launched      user volume                  @ prefix             Is this case
  50. from...       present?      User name      set to...            detectable?
  51. _____________________________________________________________________________
  52. local         maybe         any name       application prefix   yes
  53.  
  54. net           yes           (not guest)    user folder          yes
  55.  
  56. net           no            any name       application prefix   yes
  57.  
  58. net           yes           guest          guest folder         yes
  59.  
  60. net           yes           same as        user folder          special
  61.                             another user                        programming
  62.                                                                 required
  63. _____________________________________________________________________________
  64.  
  65. Table 1-Possible @ Prefix Configurations
  66.  
  67. Consider the third case.  Although the application was launched from a server, 
  68. the server does not contain a user's folder, nor is there any other mounted 
  69. server containing a user's folder.  In this case, if multiple users launch a 
  70. single copy of the application from the same folder at the same time, each 
  71. user's @ prefix would point to the same folder from which they all had 
  72. launched the application.  By denying other users write access when opening 
  73. the file, you prevent users from overwriting each other's data.  However, the 
  74. other users are no longer prevented from overwriting the data when the user 
  75. with write access closes the file, at which point a different user can write 
  76. to the file.  Therefore, using access privileges in combination with the @ 
  77. prefix deters one user's data from being overwritten by another, but only so 
  78. long as the file remains opened by the user with write access.  This approach 
  79. may provide sufficient protection for saving certain user configuration and 
  80. preference information.
  81.  
  82. When saving work the user plans to resume later, this approach may not provide 
  83. sufficient protection.  In this situation, conflicts can also arise if the @ 
  84. prefix is set to the application prefix rather than to the user's folder.  It 
  85. is up to the programmer to determine whether to use the @ prefix, how to use 
  86. it, and whether this level of protection is sufficient for the particular data 
  87. involved.
  88.  
  89. In addition to using the @ prefix (or the user path to which it attempts to 
  90. refer) with access that denies other users permission to write to the file, 
  91. applications can check to see if the user path could point to the same folder 
  92. for multiple users at the same time.  To do this, the application first checks 
  93. to see if it was launched across the network.  This is the case when class one 
  94. GetFileInfo on the user path returns fileSysID = $0D.  If the application was 
  95. launched across the network, the user path could be set the same for multiple 
  96. users if the user has logged on as a guest (UserInfo returns a null userName, 
  97. the fourth case in Table 1) or if you are using the @ prefix and the system 
  98. has set it to the application prefix on a non-user network volume (error $60 
  99. from GetUserPath, the third case in Table 1).  If the application determines 
  100. that the user prefix may be set the same for multiple users, then it could use 
  101. an alternate approach to determine where the data is to be stored, by 
  102. prompting the user for example.
  103.  
  104. Although it would be comparatively difficult for an application to determine 
  105. whether multiple users with the same name were running the application from 
  106. the same server (the fifth case in Table 1), the documentation for the 
  107. application could warn against this.  The system does not provide any specific 
  108. information about when this condition occurs.
  109.  
  110.  
  111. One More Caution
  112.  
  113. One other caution to observe when using the @ prefix:  since other 
  114. applications are also storing data in the same user's folder, each application 
  115. should be careful to reference distinct files.  Regardless of how the 
  116. application chooses to do this--by checking that the file being created does 
  117. not already exist, by choosing a distinct name for the file, or by some other 
  118. method--it should usually operate only on files of its own creation.
  119.  
  120. Programmers should keep in mind that the @ prefix is provided as a programming 
  121. convenience.  The AppleShare FST also provides the GetUserPath and UserInfo 
  122. calls.  In combination with GetFileInfo, these calls allow programmers to 
  123. devise other, more customized approaches for determining where to save the 
  124. user's data.
  125.  
  126.  
  127. Further Reference
  128. _____________________________________________________________________________
  129.   o  AppleShare Programmer's Guide for the Apple II Family
  130.   o  GS/OS Reference
  131.   o  GS/OS Technical Note #10, How Applications Find Their Files
  132.  
  133.